Field of the Invention
This invention relates to systems and methods for caching reads in data replication environments.
Background of the Invention
In data replication environments such as Peer-to-Peer-Remote-Copy (“PPRC”) environments, data is mirrored from a primary storage device to a secondary storage device to maintain two consistent copies of the data. The primary and secondary storage devices may be located at different sites, perhaps hundreds or even thousands of miles away from one another. In the event the primary storage device fails, I/O may be redirected to the secondary storage device, thereby enabling continuous operations. When the primary storage device is repaired, I/O may be redirected back to the former primary storage device. The process of redirecting I/O from the primary storage device to the secondary storage device when a failure or other event occurs may be referred to as a swap or HyperSwap.
HyperSwap is a function provided by IBM's z/OS operating system that provides continuous availability for disk failures by maintaining synchronous copies of primary disk volumes on one or more secondary storage controllers. When a disk failure is detected at a primary site, a host system running the z/OS operating system identifies HyperSwap managed volumes. Instead of rejecting I/O requests, the host system uses the HyperSwap function to switch (or swap) information in internal control blocks so that I/O requests are driven against synchronous copies at the secondary site. Since the secondary volumes are identical copies of the primary volumes prior to the failure, the I/O requests will ideally succeed with minimal impact (i.e., delay in I/O response times) on the issuing applications. Unfortunately, although secondary volumes may contain identical copies of data in the primary volumes, the cache at the secondary site may not be populated with the same data as cache at the primary site. This may cause a decrease in performance when swapping from primary volumes to secondary volumes, at least until cache at the secondary site can be fully populated with data.
In view of the foregoing, what are needed are systems and methods to ensure that cache at a secondary site is populated like cache at a primary site. Ideally, such systems and methods will ensure that, after a swap has occurred, I/O performance at a secondary site will mirror as much as possible I/O performance at a primary site.